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The instant application is related to two concurrently assigned and concurrently filed 



U.S. Patent Applications, Performance Markers to Measure Performance of 



Features in a Program, Serial No. 



, filed 



, (Attorney 



Docket M&G 40062.69-US-Ol) and Performance Markers to Measure Benchmark 
Timing of a Plurality of Features in an Application Program, Serial No. 



This apphcation relates in general to a method, apparatus, and article of manufacture 
for providing performance markers for testing of applications, and more particularly to a 
method, apparatus, and article of manufacture for inserting performance markers into 
15 programs to obtain and provide benchmark timing data regarding the run-time operation of 
the programs. 

Background of the Inventioii 

One problem facing application program developers is how their application 
20 programs are to be tested. In order for the developers to test these programs, the developers 
need access to runtime state information regarding the internal operation of the program. 
This data can include memory usage, memory location contents, timing measurements for the 
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execution of portions of the program, and similar data related to the state of the program 
while executing. 

In the past, apphcation developers have needed to use third party tools to re- 
instrument the target application (an example of this being post hnker tools like Profilers 

5 which modify the application for the purpose of adding measurement code) with instructions 
that maintain and store the needed state data in locations that provide access by the 
developers. In doing this, the application developers are changing the application program 
being developed by artificially inserting this additional code. This insertion of code impUes 
that the application developers are actually testing a program that is different from the 

10 apphcation program, which is uhimately delivered to end users. These differences caused by 
the insertion of this test code may or may not affect the ability of a programmer to adequately 
test the application program in an environment as close to the end user's working 
environment as possible. Additionally, the location of these insertion points is quite often 
Hmited to fimction call boundaries increasing the granularity at which the timings can be 

15 taken. This limits the precision of the measurements. 

This situation is especially acute to benchmark testing in which the developer wishes 
to measure the time the application program requires to perform a certain code block of 
functionality. In benchmarking, the insertion of extra instructions related to the collection of 
internal data causes the application program to perform additional instructions not included 
20 in the final application program version. These additional instructions would, in fact, be part 
of the instructions executed during benchmark testing of the program used for this testing. 
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As a result, current benchmark testing is inherently inaccurate in that the tested program is 
not the actual program delivered to end users. 

There is also a non-insertion method by which developers perform benchmarking. 
Currently, the non-insertion techniques used by developers who attempt to perform 
5 benchmark testing include a variety of methods that estimate when the program reaches the 
desired target points within the code. These external techniques include visually detecting a 
display of events that occur on the computers monitor. Often these methods also include 
attempting to synchronize the operation of the application program with a test control 
program also running on the computer. The control program performs the timing 
10 measurement and tries to externally determine via the visual cues, call backs, or events 

detectable via the message queue when to stop the timing. This technique has a low level of 
accuracy due to the control program essentially estimating when to start and/or stop the 
timings. It is limited to the granularity of measurement achievable via the visual cues as well 
as the inconsistent time occurring between the control program registering the start timing 
1 5 and the invocation of the user interface or programmatic interface action which begins the 
functionality to be timed. Additionally, the use of this external test control program also 
changes the testing environment for the application program in that a second process is 
concurrently running with the application program being tested. This second program or 
process is consuming computer resources such as processing time and memory. As a result, 
20 any results obtained using this method does not accurately represent the results, which 

occurred in the final version of the application program run within a typical user's working 
environment. To avoid the overhead of the control program, the timings are sometimes 
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performed by use of a stopwatch but this adds an inconsistent and non-negligible overhead 
both in the starting and the stopping of the timings, and also relies on visual cues making it 
inherently inaccurate. 

Application developers are in need of a mechanism to insert permanent target points 
to apphcation programs in a manner which does not significantly increase the overhead 
requirements for the application program while still providing the developers with a 
mechanism to collect and report the internal operating state data for the application program 
at precise intervals. In addition, application developers need a mechanism by which this 
testing process may be easily enabled, disabled, and configured to perform a large variety of 
different tests. 

Smnmary of the Invention 

In accordance with the present invention, the above and other problems are solved by 
providing a method, apparatus, and article of manufacture for inserting performance markers, 
also generically referred to as code markers, into programs to obtain and provide benchmark 
timing data regarding the run-time operation of the programs. 

One aspect of the present invention is a computing system having a mass storage 
device and a system timer for obtaining benchmark timing for a portion of an application 
program execution. The computing system has an init module for determining if the 
timestamp data is to be collected during the operation of the apphcation program, a 
performance marker module for obtaining and storing the timestamp data for later retrieval, 
an uninit module for formatting and storing the obtained timestamp data into a data file 
within the mass storage device that permits retrieval after the termination of the application 
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program, and a performance benchmark data post processing module for determining the 
benchmark timing from two or more timestamp data entries. The init module is executed 
before any timestamp data is collected. The performance marker module is executed each 
time benchmark timestamp data and overhead timestamp data is to be collected. The uninit 
module is executed after all timestamp data desired has been collected and just before the 
application exits. The performance benchmark data post processing module determines the 
benchmark timing from timestamp entries stored within the data file. 

Another such aspect is a method for obtaining benchmark timing for a portion of an 
application program execution. The method includes inserting one or more code markers into 
the application program at locations within the application program corresponding to the 
point at which benchmark timing data is desired and determining if benchmark timing data is 
to be collected at each code marker by checking for the existence of processing modules 
identified by an identification key within a system registry. If benchmark timing data is to be 
collected at each code marker, the method generates a benchmark data record containing the 
collected benchmark timing data each time the code markers are reached, stores the 
benchmark data records within a data memory block within the processing modules identified 
by the identification key within the system registry, retrieves the benchmark data records 
from the data memory block for transfer to a mass storage device once all of the run-time 
internal state data has been collected, and processes the benchmark data records stored within 
the mass storage device to determine the benchmark timing defined between two benchmark 
data records. 

Yet another aspect of the present invention is a computer data product readable by a 
computing system and encoding a computer program of instructions for executing a computer 
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process for obtaining run-time internal state data within an application program, The 
computer process comprising the steps of inserting one or more code markers into the 
application program at locations within the application program corresponding to the point at 
which benchmark timing data is desired and determining if benchmark timing data is to be 

5 collected at each code marker by checking for the existence of processing modules identified 
by an identification key within a system registry. If benchmark timing data is to be collected 
at each code marker, the computer process generates a benchmark data record containing the 
collected benchmark timing data each time the code markers are reached, stores the 
benchmark data records within a data memory block within the processing modules identified 

10 by the identification key within the system registry, retrieves the benchmark data records 
from the data memory block for transfer to a mass storage device once all of the run-time 
internal state data has been collected, and processing the benchmark data records stored 
within the mass storage device to determine the benchmark timing defined between two 
benchmark data records. 

15 The invention may be implemented as a computer process, a computing system or as 

an article of manufacture such as a computer program product. The computer program 
product may be a computer storage medium readable by a computer system and encoding a 
computer program of instructions for executing a computer process. The computer program 
product may also be a propagated signal on a carrier readable by a computing system and 

20 encoding a computer program of instructions for executing a computer process. 

The great utility of the invention is that it provides application program developers with a 
mechanism for inserting performance markers into programs to obtain and provide data 

Page 6 

Microsoft Corp. 
Patent Application 



regarding the run-time operation of the programs. These and various other features as well as 
advantages, which characterize the present invention, will be apparent from a reading of the 
following detailed description and a review of the associated drawings. 



5 Brief Description of the Drawings 

Referring now to the drawings in which like reference numbers represent 
corresponding parts throughout: 

Fig. 1 illustrates an application program testing system according to one embodiment 
of the present invention. 

10 Fig. 2 illustrates a general purpose computing system for use in implementing as one 

or more computing embodiments of the present invention. 

Fig. 3 illustrates another application program testing system according to another 
embodiment of the present invention. 

Fig, 4 illustrates a performance benchmark statically linked library and a performance 
15 benchmark dynamically Unked library for use in program testing according to an example 
embodiment of the present invention. 

Fig, 5A illustrates a sample performance benchmark data record according to an 
embodiment of the present invention. 

Fig. 5B illustrates a sample performance benchmark data file according to an 
20 embodiment of the present invention. 

Fig. 5C illustrates a timing sequence for code marker benchmark timing according to 
an embodiment of the present invention. 
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Fig. 6 illustrates an operational flow for an initialization module within a performance 
markers module according to an embodiment of the present invention. 

Fig. 7 illustrates an operational flow for a markers data module within a performance 
markers module according to another embodiment of the present invention. 

Fig. 8 illustrates an operational flow for an uninitalization module within a 
performance markers module according to another embodiment of the present invention. 

Detailed Description of the Invention 

This is an application to a method, apparatus, and article of manufacture for inserting 
performance markers into programs to obtain and provide benchmark timing data regarding 
the run-time operation of the programs. 

Fig. 1 illustrates an application program testing system according to one embodiment 
of the present invention. Typically, when an application program 101 is being tested, the 
application program 101 interacts with a test measurement system 102 in order to control the 
operation of the application program 101 during the test. The test measurement system 102 
transmits a run command 121 to the application program being tested 101 to instruct the 
program 101 to begin its operations. A user typically has inserted one or more code markers 
within the application program 101 to indicate the points during the operation of the 
application program 101 in which runtime data is desired. When the operation of the 
application program 101 reaches a code marker, a code marker indication 122 is transmitted 
to the test measurement system 102. 
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The test measurement system 102 uses the receipt of a code marker indication 122 as 
an indication that the application program 101 has reached one of the previously defined code 
markers. At this point in time, the test measurement system 102 may obtain runtime data 
from the application program 101 for storage within a memory buffer, storage within a mass 
storage device 1 1 1 or display upon a user's terminal 112. The test measurement system 102 
will provide the application program 101a second run command 121 to indicate to the 
apphcation program 101 that it should resume its operation until another code marker is 
reached. If the test measurement system 102 wishes to obtain timing information regarding 
how long a particular operation within the apphcation program 101 take to perform, the test 
measurement system 102 may obtain a time stamp for a first code marker from a timing 
device 103. If time stamps are obtained by the test measurement system 102 at the beginning 
and end of a desired operation, the test measurement system 102 may determine how long it 
took for an apphcation program 101 to perform the operation simply by comparing the 
difference between the two times. 

Other performance measurements may be obtained in a similar manner to the timing 
measurements discussed above by obtaining run-time state data, such as the registry 
transactions, all file I/O transactions that occur including read operations, write operations, 
and delete operations performed on a given file, and similar usefiil system test data at the 
various code markers. Comparing the states of the program 101 at the code markers allows a 
user to determine what processes occurred between any two user defined code markers set 
within the program 101. 

With reference to Figure 2, an exemplary system for implementing the invention 
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includes a general-purpose computing device in the form of a conventional personal 
computer 200, including a processor unit 202, a system memory 204, and a system bus 206 
that couples various system components including the system memory 204 to the processor 
unit 200. The system bus 206 may be any of several types of bus structures including a 
memory bus or memory controller, a peripheral bus and a local bus using any of a variety of 
bus architectures. The system memory includes read only memory (ROM) 208 and random 
access memory (RAM) 210. A basic input/output system 212 (BIOS), which contains basic 
routines that help transfer information between elements within the personal computer 200, is 
stored in ROM 208. 

The personal computer 200 further includes a hard disk drive 212 for reading from 
and writing to a hard disk, a magnetic disk drive 214 for reading from or writing to a 
removable magnetic disk 216, and an optical disk drive 218 for reading from or writing to a 
removable optical disk 219 such as a CD ROM, DVD, or other optical media. The hard disk 
drive 212, magnetic disk drive 214, and optical disk drive 218 are connected to the system 
bus 206 by a hard disk drive interface 220, a magnetic disk drive interface 222, and an optical 
drive interface 224, respectively. The drives and their associated computer-readable media 
provide nonvolatile storage of computer readable instructions, data structures, programs, and 
other data for the personal computer 200. 

Although the exemplary environment described herein employs a hard disk, a 
removable magnetic disk 216, and a removable optical disk 219, other types of computer- 
readable media capable of storing data can be used in the exemplary system. Examples of 
these other types of computer-readable mediums that can be used in the exemplary operating 
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environment include magnetic cassettes, flash memory cards, digital video disks, Bemoulli 
cartridges, random access memories (RAMs), and read only memories (ROMs). 

A number of program modules may be stored on the hard disk, magnetic disk 216, 
optical disk 219, ROM 208 or RAM 210, including an operating system 226, one or more 

5 application programs 228, other program modules 230, and program data 232. A user may 
enter commands and information into the personal computer 200 through input devices such 
as a keyboard 234 and mouse 236 or other pointing device. Examples of other input devices 
may include a microphone, joystick, game pad, satellite dish, and scanner. These and other 
input devices are often connected to the processing unit 202 through a serial port interface 

10 240 that is coupled to the system bus 206. Nevertheless, these input devices also may be 
connected by other interfaces, such as a parallel port, game port, or a universal serial bus 
(USB). A monitor 242 or other type of display device is also connected to the system bus 
206 via an interface, such as a video adapter 244. In addition to the monitor 242, personal 
computers typically include other peripheral output devices (not shown), such as speakers 

15 and printers. 

The personal computer 200 may operate in a networked environment using logical 
connections to one or more remote computers, such as a remote computer 246. The remote 
computer 246 may be another personal computer, a server, a router, a network PC, a peer 
device or other common network node, and typically includes many or all of the elements 
20 described above relative to the personal computer 200. The network connections include a 
local area network (LAN) 248 and a wide area network (WAN) 250. Such networking 
environments are commonplace in offices, enterprise-wide computer networks, intranets, and 

Page 1 1 

Microsoft Corp. 
Patent Application 



the Internet. 

When used in a LAN networking environment, the personal computer 200 is 
connected to the local network 248 through a network interface or adapter 252. When used 
in a WAN networking environment, the personal computer 200 typically includes a modem 

5 254 or other means for estabhshing communications over the wide area network 250, such as 
the Internet. The modem 254, which may be internal or external, is connected to the system 
bus 206 via the serial port interface 240. In a networked environment, program modules 
depicted relative to the personal computer 200, or portions thereof, may be stored in the 
remote memory storage device. It will be appreciated that the network connections shown 

10 are exemplary, and other means of establishing a communications link between the 
computers may be used. 

Additionally, the embodiments described herein are implemented as logical 
operations performed by a computer. The logical operations of these various embodiments of 
the present invention are implemented (1) as a sequence of computer implemented steps or 
15 program modules running on a computing system and/or (2) as interconnected machine 

modules or hardware logic within the computing system. The implementation is a matter of 
choice dependent on the performance requirements of the computing system implementing 
the invention. Accordingly, the logical operations making up the embodiments of the 
invention described herein can be variously referred to as operations, steps, or modules. 

20 Fig. 3 illustrates another application program testing system according to another 

embodiment of the present invention. An apphcation program 101 being tested consists of an 

Page 12 

Microsoft Corp. 
Patent Application 



application main body module 301, one or more application specifically defined statically 
linked libraries 302-304, one more application specifically defined dynamically linked 
libraries 3 12-3 14, a performance benchmark statically linked library 305, and a performance 
benchmark dynamically linked library 315, In the past, application programs typically 
consisted of all the above modules with the exception of the performance benchmark 
statically hnked library 305 and the performance benchmark dynamically linked library 315. 
An application developer who writes the application program 101 has specified a collection 
of processing modules, which may not be organized into the various libraries. These 
modules are combined together to create the application program 101 that the application 
developer wishes to test. 

The application developer tests the operation of the apphcation program 101 by 
inserting within any of the application specific modules 301-304 and 312-314 one or more 
code markers. These code markers comprise function calls to modules within the 
performance benchmark statically linked library 305. The functionaUty that is to be 
performed at a particular benchmark code marker is implemented within these function calls. 
This fimctionality may be located within either the performance benchmark statically Hnked 
library 305 or the performance benchmark dynamically linked library 315. 

The runtime data that the application developer wishes to obtain at each of these code 
markers is stored within the mass storage device 1 1 1 and may be examined and further 
processed within a performance benchmark data post processing module 316. In order to 
minimize the runtime overhead associated with the implementation of the processing for a 
given code marker, the data collected at a particular code marker is stored within memory of 
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the performance benchmark dynamically hnked library 315 and ultimately transferred to the 
mass storage device 111. Processing of the data collected and displaying the data to an 
application developer performing a test is performed by the performance benchmark data 
post processing modules 316. By performing the benchmark data analysis processing end 
data display functions within a data post processing module 316, the amount of processing 
performed at runtime to implement a code marker is minimized. 

Fig. 4 illustrates a performance benchmark statically hnked library and a performance 
benchmark dynamically linked library for use in program testing according to an example 
embodiment of the present invention. The performance benchmark statically linked library 
305 and the performance benchmark dynamically linked library 315 implement the 
functionahty needed to insert code marker data collection within an application program 101. 
The performance benchmark statically linked library 305 comprises three modules: a linked 
Init module 401, a linked performance marker module 402, and a linked unlnit module 403. 
The linked Init module 401 is accessed using an Init call 411 that is called once at the 
beginning of the application program 101 that is being tested. The performance marker 
module 402 is accessed using a marker call 412 which is called each time a benchmark code 
marker inserted within the apphcation program 101 is reached. Finally, the Linked unlnit 
module 403403 is accessed using an uninit call 413. The uninit call 413 is called once at the 
end of the execution of the apphcation program 101 to complete the data collection process. 

The processing performed to implement the code markers requires the data collection 
processing modules that hold the runtime state data be initiahzed before any of the code 
markers are reached. This initiahzation process occurs within the linked init module 401 . 
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Once the data collection processing modules have been initialized, any number of code 
markers may be called using the marker call 412 to the linked performance marker module 
402. Each code marker will cause a corresponding call to the linked performance marker 
module 402, which in turn captures and stores the benchmark runtime data into the data 
5 collection processing modules. In addition, each code marker generates and stores a 
benchmark data record into a computer systems memory containing the captured data. 

When the processing has been completed, a single unlnit call 413 is made to the 
Unked unlnit module 403 to retrieve all of the benchmark data records from memory for 
storage onto the mass storage device 111 and/or display to an application developer on his or 
10 her terminal 1 12. The benchmark data records are stored within a file system on the mass 
storage device 1 1 1 in order to allow the records to be accessed and analyzed using a 
performance benchmark data post processing module 316. 

Within each of the three processing modules within the performance benchmark 
statically linked library 305, the processing simply includes a function call to corresponding 

1 5 dynamically linked libraries (DLL) within the performance benchmark dynamically linked 
libraries 315. With such an arrangement, a single performance benchmark statically linked 
library 305 may be statically linked within an application program 101, and may be small in 
size, while permitting the particular functionality to be performed within a benchmark test to 
be defined within the dynamically linked hbraries. As such, a single mechanism may be used 

20 within an application program 101 that easily allows a plurality of different tests to be 
performed simply by changing the identity of the performance benchmark dynamically 
linked library 315 that are used as part of a single test. 
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The linked Init module 401, when called at the beginning of application program 101, 
obtains the identity of the dynamically hnk library to be used for a particular test. This 
identity of the dynamically linked libraries is typically stored within a registry key in the 
system registry of the computing system. If the registry key which identifies the dynamically 
hnked library is not found within the registry, the linked init module 401 determines that any 
benchmark code markers encountered are not to perform any processing. Therefore, a 
appUcation program 101 may be shipped to an end user without the performance benchmark 
dynamically Hnked libraries 315 and the corresponding system registry entries, where any 
benchmark code markers inserted within the application program 101 will not result in the 
performance of any additional processing. 

Within the linked init module 401, the processing also determines whether the 
dynamically link library 315, which has been identified by a system registry key, actually 
exists on the computing system. If this dynamically hnked library does not exist even though 
a registry key exists, or if the dynamically linked library corresponding to the registry key 
does not contain the expected functions, the Init module 401 also determines that the code 
marker processing is not to occur. 

The linked code marker module 402, which is called each time a code marker is 
reached, simply checks to see if the hnked Init module 401 determined that code marker 
processing is to occur. If this code marker processing is not to occur, the code marker 
module 402 merely returns to the calling apphcation program 101. If the module 401 had 
determined that code marker processing is to occur, the code marker module 401 takes a 
timing measurement and then calls the marker DLL module 422 with this timing as an input 
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parameter. The DLL module 422 may store this timing data or decide to collect some other 
required runtime state data and to store this runtime state data within a performance marker 
data memory block 424. By having the statically linked code marker module make a timing 
measurement and then pass that timing measurement into the DLL module 422, there is a 

5 minimal amount of time delay occurrence between when the developer has chosen to make 
the timing and when it actually occurs. There is thus only a small and negligible overhead 
that occurs due to the clock cycles involved in making a function call to the statically linked 
code marker module 402. The marker DLL module 422 generates a performance data record 
for each corresponding code marker called to the marker DLL 422. These performance data 

10 records are simply stored as a concatenated array of records within the memory block 424. 

Once all the processing has been completed, the unlnit module 404 is called using 
unlnit call 413. This module 404 also checks to determine if the Init module 401 has 
indicated that benchmark processing is to occur. If this benchmark processing is not to 
occur, the linked unlnit module 404 simply returns to the application program 101 . If the 

15 benchmark processing is to occur, the linked uninit module 404 calls the corresponding 
unlnit DLL module 423. The unlnit DLL 423 module retrieves all of the benchmark data 
records from the memory block 424, formats them appropriately, and stores these records 
within the mass storage device 111. Once these records reach the mass storage device 111, 
further analysis, review, and subsequent processing may be performed by the application 

20 developer as needed. 

Because the particular benchmark code marker process that is to occur during a given 
test is implemented with in the three DLL modules 421-423, the performance benchmarks, 
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according to the present invention are readily extensible in that a single yet simple interface 
to a data collection mechanism may be specified in which the particular nature of the test 
performed does not need to be embedded in the application program 101. In fact, this 
processing is contained completely within the set of three DLL modules 421-423. 
Additionally, the overhead associated with embedding the calls to the performance 
benchmark modules within an appHcation program may be minimized. This fact is further 
emphasized by including all of the state difference processing needed to determine how long 
a block of code requires for execution and to determine which state variables have changed 
during the execution of a given segment of code, within the post processing operations 
performed on the set benchmark data records. 

Fig. 5A illustrates a sample performance benchmark data record according to an 
embodiment of the present invention. Each benchmark data record 501 comprises a plurality 
of data fields used to represent the current state of an application program 101 at the time a 
code marker is reached. The record 501 includes an application identifier 511 that is used to 
identify uniquely the application program 101 from which the data record was generated. 
The record 501 includes a code marker Identifier 512 which is used to identify the particular 
code marker that generated this data record 501. Finally, the data record 501 includes two 
timestamp data fields, a Benchmark Timestamp data 513 and an Overhead Timestamp data 
514. 

The Benchmark Timestamp data 513 is obtained immediately after the code marker 
has been reached. As discussed above in Fig. 4, the code marker will generate a function call 
to the Linked Performance Marker module 402 within the Performance Marker Link Library 
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module 305. This time stamp is obtained within the Linked Performance Marker module 402 
immediately after it is determined that the performance marker processing is to occur. The 
timestamp is obtained as soon as possible to attempt to minimize the latency between the 
application program's arrival at the code marker within its code and the execution of the 
instructions that actually obtain the timestamp measurement. 

Once this time stamp data has been obtained, a call is made to the Marker_DLL 
module 422 to complete the performance marker processing. Once this processing has been 
completed, a second timestamp is obtained. This second timestamp, an Overhead Timestamp 
data 514, represents the best approximation for the time at which the processing returned 
from the performance marker processing performed within the Linked Performance Marker 
module 402 and the Marker_DLL module 422. The second timestamp completes the 
benchmark data record 501 that is stored within the performance marker data memory block 
424. 

Fig. 5B illustrates a sample data file 502 for a benchmark process that determines the 
time required to perform various operations within an application program 101 . Each data 
record comprises four fields: an AppID 521, a code marker ID 522, a time stamp for a code 
marker timestamp 523, and a time stamp for an overhead timestamp 524. The time stamps in 
this illustrated embodiment may be obtained from a system timer/counter found within many 
computing systems. This system timer is related to the operating clocks used within a 
computing system and thus relates directly to the time, measuring clock cycles, required to 
reach a particular point in the execution of the program. As such, the difference between 
various time stamps, after subtracting any overhead time, would represent the amount of 
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time, as measured in clocks cycles, needed to perform the processing between any two code 
markers. The overhead time estimate is determined by calculating the difference between the 
Benchmark Timestamp data 513 and the Overhead Timestamp data 514. 

Fig. 5C illustrates a timing sequence for code marker benchmark timing according to 
an embodiment of the present invention. The timing diagram illustrates a sequence of four 
code markers BPl 531, BP2 534, BP3 537, and BP4 540. Each of these code markers 
conesponds to a point in time at which the application program 101 reached each of four 
code markers placed within its code. As discussed above, each of these four code markers 
also obtains four additional timestamps, OHl 532, 0H2 535, 0H3 538, and 0H4 541 that 
measure an estimate for the time at which the processing returned from the performance 
marker libraries 305, 315 to the appUcation program lOL 

In Fig. 5C, a benchmark At 551 represents the time required for the application 
program 101 to complete the processing that occurs between BPl 531 and BP4 540. Because 
the processing time for this task also includes processing associated with obtaining and 
storage of the various code markers, the estimate for the overhead processing, in this example 
Atl 533, At2 536, and At3 538, must be subtracted from the difference between BPl 531 and 
BP4 540. Each of the overhead processing estimates is determined from the difference 
between the benchmark time stamp and the overhead timestamp. For example, 

At2 536 - 0H2 535 - BP2 534. (1) 
The same determination may be made for each of the other time stamps obtained during a 
test. In addition, the timestamp is measured in units of clock cycle counts in the preferred 
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embodiment. As such, all time measurements discussed herein need to be scaled by the time 
for a single clock cycle if measurements in seconds is desired. 

Given the above explanation, the measurement of an accurate benchmark is obtained 
by calculating the difference between two time stamps, BP4 540 and BPl 531, for example. 
5 The accurate benchmark is calculated by subtracting an estimate of all of the time spent 
within performance marker libraries 305, 314, from the above difference. In the example in 
Fig. 5C, the accurate benchmark is: 

Benchmark = (BP4 540 - BPl 531) - (Atl 533 + At2 536 + At3 539). (2) 
All of this processing to determine the benchmark timing is performed as part of the 
10 Performance Benchmark Data Post Processing module 3 1 6 that is run after the application 
program 101 has completed its operations. 

Fig. 6 illustrates an operational flow for an initialization module withm a performance 
markers module according to an embodiment of the present invention. The processing within 
the initiaUzation process 601 proceeds to an Init module 611. Within the Init module 611, 
1 5 the main application module calls the performance marker init module 401 in order to 

initiahzed the data memory block 424 used to hold a collection of benchmark data records. 
Once complete, the processing proceeds to the Reg Key Check module 612. This module 
612 checks a DLL registry key within a system registry on the computer. This registry key 
provides the identity to a dynamically linked library containing the processing modules 
20 needed to implement the code marker processing. 

Test module 613 determmes whether this registry key exists. If not, processing 
branches to a Marker Flag False module 618. If a registry key does exist, as determined by 
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test module 613, processing proceeds to DLL check module 614. This module 614 checks 
for the presence of the DLL modules within the system as identified in by the previously 
checked registry key. This module 615 determines the outcome of the previous check for the 
existence of the DLL module. If the DLL module does not exist, processing again branches 
to Marker Flag False module 618. 

If the DLL module identified by the registry key exists, processing branches to Data 
Memory Configuration module 616. This configuration module 616 initializes and configures 
a performance marker data memory block 424 within the DLL. This memory block is used 
to hold the collection of the benchmark data records generated by the performance 
benchmarking process. Once complete, a Flag Marker True module 617 sets a marker flag to 
be true. This flag is used by other processing the to indicate whether not a performance 
benchmark processing is to occur. Once this processing has completed, the processing ends 
602. 

Retuming to either test operation 612, or 615, if either of these tests are determined to 
be false, the processing proceeded to Marker Flag False module 618. This flag module 61 8 
sets the marker flag to be false, thus indicating to the processing that performance benchmark 
processing is not to occur because either the DLL does not exist or the registry key that 
identifies the DLL to be used does not exist. Once this flag is been set, the processing also 
ends 602. 

Fig. 7 is an operational flow for a markers data module within a performance markers 
module according to another embodiment of the present invention. Within the code marker 
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processing, the processing starts 701 and test module 711 immediately determines whether 
benchmark processing is to occur. In one embodiment, this test checks the marker flag that 
narrow has been previously set within the initialization process. If the code marker 
processing is not to occur, the processing merely branches to the end 702. As such a 

5 benchmark code marker processing simply results in a call to a statically linked library 
routine which checks a flag and immediately returns back to the main processing modules. 
As such, the overhead associated with the execution of an application program containing 
performance marker is quite minimal. This approach allows application programs to contain 
performance markers used to test and evaluate the performance of the application program in 

10 the program itself as they would ship to end users. This testing that occurs need not be 
performed on a modified version of the application program which does not represent the 
state of the product which is actually ship to end users. This operation overhead processing 
does not impinge upon the performance of the application program itself, while still 
providing an extensible means by which the testing of the application program may be 

15 performed. 

If the flag indicates that performance code markers are to be processed, processing 
proceeds to the Obtain Breakpoint Timestamp module 712. This module 712, which is 
located within the link library, obtains the first of two timestamp data measurements. This 
timestamp data measurement corresponds to the Benchmark Timestamp data 513 within the 
20 benchmark data record 501. Next call marker DLL module 713 calls the DLL module to 

gather any additional data relating to the state of the application program at the time the code 
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marker is reached. This module 713 passes the Benchmark Timestamp data 513 value to the 
Marker_DLL 422 for use in generating the benchmark data record 501. 

Store Marker Data Module 714 generates the benchmark data record 501 using the 
Benchmark Timestamp data 513 value passed from the call marker DLL module 713. This 

5 Store Marker Data module 714 then stores the generate benchmark data record 501 within the 
performance marker data memory block 424. As part of this process, a benchmark data 
record is generated within a format desired for the particular data being collected. Once the 
data has been stored, an Overhead Timestamp module 715 may obtain a second timestamp 
measurement and store the obtained value within the Overhead Timestamp Data field 514 of 

10 the benchmark data record 501 . As discussed above, the timing data typically includes a time 
stamp associated with the beginning of the benchmark code marker processing. 

Because the above collection of modules that are needed to obtain the data, format the 
data, and store the data within the memory block 424 takes some measurable amount of 
processing time, as measured in clock cycles, to perform its operations, a more accurate 

15 estimate for a benchmark for the processing that occurs between two code markers would 
attempt to subtract the time spent within all of these benchmark modules. As such, this 
record may include a second time stamp associated with time at which the processing returns 
back to the main appHcation. The second time stamp may be generated and stored within the 
memory block by the Overhead Timestamp module 715. With all of the data now collected 

20 and stored within the memory block 424, the processing ends 702. 
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Fig. 8 is an operational flow for an uninitalization module within a performance 
markers module according to another embodiment of the present invention. Within the 
unlnit processing, the processing starts 801, and tests module 811 immediately determines 
whether benchmark processing is to occur. In one embodiment, this test module 811 checks 

5 the marker flag that had been previously set within the initiaUzation process. If the code 
marker processing is not to occur, the processing merely branches to the end 802. As such, 
the unlnit processing simply results in a call to the linked library routine which checks a flag 
and immediately returns back to main processing. As discussed above, this sequence of 
operations imposes a minimal amount of processing upon an apphcation program 101 when 

10 sent to the end user without the performance marker DLLs. 

If performance marker processing is to occur, this set of modules formats and stores 
the collected set of benchmark data records for later use. The processing proceeds from test 
operation 81 1 to a Call unlnit DLL module 812. This module 812, which is located within 
the statically link library, calls the DLL module to move the collection of benchmark data 

15 records from the DLL memory block 424 to mass storage 111. Typically, these records are 
stored within a file in the computer's file system for later use. This data may be stored in 
either a binary format, or may be converted into a human readable form. Because the uninit 
process occurs at the end of the testing process, occurs only once, and occurs after all time 
critical events are over, this data conversion processing may occur within the DLL modules 

20 without affecting the results from the testing. Alternatively, this data formatting operation 
may occur within the post processing modules 316 at a later date. Once the data has been 
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stored for later use, a Free Memory Block module 814 performs any system housekeeping 
processing necessary to free the memory used by the DLL modules that is no longer needed. 

Thus, the present invention is presently embodied as a method, apparatus, computer 
storage medium, or propagated signal containing a computer program for manufacture for 
5 inserting performance markers into programs to obtain and provide data regarding the run- 
time operation of the programs. 

While the above embodiments of the present invention describe insertion of 
performance markers into programs to obtain and provide data regarding the run-time 
operation of the programs, one skilled in the art will recognize that the type of run- time data 

10 collected and returned to a user may represent any data collectable from the computing 

system and its operating state. As long as the performance markers are inserted within the 
application program at the locations in which the testing is to occur, and as long as the 
particular data collection processing is specified within the libraries, the present invention 
would be useable in any testing enviroimient. It is to be understood that other embodiments 

15 may be utilized and operational changes may be made without departing from the scope of 
the present invention. 

As such, the foregoing description of the exemplary embodiments of the invention 
has been presented for the purposes of illustration and description. They are not intended to 
be exhaustive or to limit the invention to the precise forms disclosed. Many modifications 
20 and variations are possible in light of the above teaching. It is intended that the scope of the 
invention be limited not with this detailed description, but rather by the claims appended 
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hereto. Thus the present invention is presently embodied as a method, apparatus, computer 
storage medium, or propagated signal containing a computer program for providing a 
method, apparatus, and article of manufacture for inserting performance markers into 
programs to obtain and provide data regarding the run-time operation of the programs. 
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Claims 



WHAT IS CLAIMED IS: 



1 1 . A computing system having a mass storage device and a system timer for 

2 obtaining benchmark timing for a portion of an application program execution, the computing 

3 system comprising: 

4 a mass storage system; 

5 an init module for determining if the timestamp data is to be collected during the 

6 operation of the application program; 

7 a performance marker module for obtaining and storing the timestamp data for later 

8 retrieval; 

9 an uninit module for formatting and storing the obtained timestamp data into a data file 

10 within the mass storage device that permits retrieval after the termination of the application 

1 1 program; and 

12 a performance benchmark data post processing module for determining the benchmark 

13 timing from two or more timestamp data entries; 

14 wherein 

15 the init module is executed before any timestamp data is collected; 

16 the performance marker module is executed each time benchmark timestamp data 

17 and overhead timestamp data is to be collected; 

18 the uninit module is executed after all timestamp data desired has been collected; 

19 and 

20 the performance benchmark data post processing module determines the 

21 benchmark timing from timestamp entries stored within the data file. 
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1 2. The computing system according to claim 1 , wherein the init module determines if 

2 timestamp data is to be collected. 

1 3. The computing system according to claim 2, wherein init module makes the 

2 determination that timestamp data is to be collected by checking for the existence of an 

3 identification key within a system registry; 

4 the identification key uniquely identifying the processing modules to be used to collect, 

5 format, and store the run-time internal state data to be collected. 

1 4. The computing system according to claim 3, wherein the timestamp data 

2 comprises a timer count value obtained from the system timer. 

1 5. The computing system according to claim 2, wherein the performance marker 

2 module collects timestamp data only if the init module has determined that the timestamp data is 

3 to be collected. 

1 6. The computing system according to claim 5, wherein the performance marker 

2 module generates a benchmark data record containing a benchmark timestamp data value each 

3 time the performance marker module is executed. 

1 7. The computing system according to claim 6, wherein the benchmark data record 

2 further containing an overhead timestamp data value each time the performance marker module is 

3 executed. 

1 8. The computing system according to claim 7, wherein the performance marker 

2 module stores the benchmark data records within a data memory block within the processing 

3 modules identified by an identification key within a system registry. 
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1 9. The computing system according to claim 8, wherein the uninit module retrieves 

2 the benchmark data records from the data memory block for transfer to the data file on the mass 

3 storage device. 

1 10. The computing system according to claim 9, wherein the performance benchmark 

2 data post processing module determines the benchmark timing from difference between two 

3 benchmark timestamp data entries stored within the data file. 

1 11. The computing system according to claim 1 0, wherein ftie performance 

2 benchmark data post processing module determines the benchmark timing by subtracting an 

3 estimate for the total overhead processing from the difference between two benchmark timestamp 

4 data entries stored within the data file. 

1 12. The computing system according to claim 1 1 , wherein the estimate for the total 

2 overhead processing is determined by totaling the difference between the overhead timestamp 

3 value and the benchmark timestamp value for all code markers between the two benchmark 

4 timestamp entries used to determine the benchmark timing. 

1 1 3 . A method for obtaining benchmark timing for a portion of an application program 

2 execution, the method comprising: 

3 inserting one or more code markers into the application program at locations within the 

4 application program corresponding to the point at which benchmark timing data is desired; 

5 determining if benchmark timing data is to be collected at each code marker by checking 

6 for the existence of processing modules identified by an identification key within a system 

7 registry; 

8 if benchmark timing data is to be collected at each code marker: 
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9 generating a benchmark data record containing the collected benchmark timing 

1 0 data each time the code markers are reached; 

1 1 storing the benchmark data records within a data memory block within the 

12 processing modules identified by the identification key within the system registry; 

13 retrieving the benchmark data records from the data memory block for transfer to 

14 a mass storage device once all of the run-time internal state data has been collected; and 

15 processing the benchmark data records stored within the mass storage device to 

16 determine the benchmark timing defined between two benchmark data records. 



1 14. The method according to claim 13, wherein the benchmark timing from difference 

2 between two benchmark timestamp data entries stored within the data file. 

1 15. The method according to claim 14, wherein the benchmark timing is determined 

2 by subtracting an estimate for the total overhead processing from the difference between two 

3 benchmark timestamp data entries stored within the data file. 

1 16. The method according to claim 1 5, wherein the estimate for the total overhead 

2 processing is determined by totaling the difference between an overhead timestamp value and a 

3 benchmark timestamp value for all code markers between the two benchmark timestamp entries 

4 used to determine the benchmark timing. 



1 17. The method according to claim 16, wherein 

2 the benchmark timestamp value is obtained from a system timer immediately after a code 

3 marker is reached; 

4 the overhead timestamp value is obtained from the system timer immediately before 

5 processing returns to the application program from performance marker processing. 
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1 1 8. A computer data product readable by a computing system and encoding a 

2 computer program of instructions for executing a computer process for obtaining run-time 

3 internal state data within an application program, said computer process comprising the steps of: 

4 inserting one or more code markers into the appUcation program at locations within the 

5 application program corresponding to the point at which benchmark timing data is desired; 

6 Determining if benchmark timing data is to be collected at each code marker by checking 

7 for the existence of processing modules identified by an identification key within a system 

8 registry; 

9 if benchmark timing data is to be collected at each code marker: 

10 generating a benchmark data record containing the collected benchmark timing 

1 1 data each time the code markers are reached; 

12 storing the benchmark data records within a data memory block within the 

13 processing modules identified by the identification key within the system registry; 

14 retrieving the benchmark data records from the data memory block for transfer to 

15 a mass storage device once all of the run-time internal state data has been collected; and 

16 processing the benchmark data records stored within the mass storage device to 

17 determine the benchmark timing defined between two benchmark data records, 

1 19. The computer data product according to claim 1 8, wherein the determining step 

2 makes the determination that benchmark timing data is to be collected by checking for the 

3 existence of an identification key within a system registry; 

4 the identification key uniquely identifies the processing modules to be used to collect, 

5 format, and store the run-time internal state data to be collected. 
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1 20. The computer data product according to claim 19, wherein the determining step 

2 further makes the determination that benchmark timing data is to be collected by checking for the 

3 existence of processing modules identified by the identification key within the system registry. 

1 21 . The computer data product according to claim 19, wherein the data memory block 

2 is within processing modules identified by the identification key within the system registry. 

1 22. The computer data product according to claim 2 1 , wherein the benchmark timing 

2 from difference between two benchmark timestamp data entries stored within the data file. 

1 23 . The computer data product according to claim 22, wherein the benchmark timing 

2 is determined by subtracting an estimate for the total overhead processing from the difference 

3 between two benchmark timestamp data entries stored within the data file. 

1 24. The computer data product according to claim 23, wherein the estimate for the 

2 total overhead processing is determined by totaling the difference between an overhead 

3 timestamp value and a benchmark timestamp value for all code markers between the two 

4 benchmark timestamp entries used to determine the benchmark timing. 



1 25. The computer data product according to claim 24, wherein 

2 the benchmark timestamp value is obtained from a system timer immediately after a code 

3 marker is reached; and 

4 the overhead timestamp value is obtained from the system timer immediately before 

5 processing returns to the application program from performance marker processing. 

1 26. The computer data product according to claim 19, wherein the computer data 

2 product comprises a computer readable storage medium readable by a computer upon which 

3 encoded instructions used to implement the computer process are stored. 
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1 27. The computer data product according to claim 1 9, wherein the computer data 

2 product comprises a propagated signal on a carrier detectable by a computing system and 

3 encoding a computer program of instructions for executing the computer process. 
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Abstract of the lavention 

A method, apparatus, and article of manufacture provide a mechanism for inserting 
performance markers into programs to obtain and provide data regarding the run-time benchmark 
timing of the programs. The computing system has an init module for determining if the 

5 benchmark timing data is to be collected during the operation of the application program, a 
performance marker module for obtaining and storing the benchmark timing data for later 
retrieval, and an uninit module for formatting and storing the obtained benchmark timing data 
into memory that permits retrieval after the termination of the appHcation program. The init 
module is executed before any benchmark timing data is colected. The performance marker 

10 module is executed each time benchmark timing data is to be collected. The uninit module is 
executed after all benchmark timing data desired has been collected. The method and computer 
data product relate to a computer implemented process that inserts one or more code markers into 
the application program at locations within the application program corresponding to the point at 
which benchmark timing data is desired and that determines if benchmark timing data is to be 

15 collected at each code marker by checking for the existence of processing modules identified by 
an identification key within a system registry. 
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In addition, I also hereby appoint the following attorneys to prosecute this application and to transact all business in the U.S. Patent and 
Trademark Office in connection therewith: 

Kate E, Sako, Reg, No. 32,628 
Daniel D, Grouse, Reg. No. 32,022 

I hereby authorize them to act and rely on instructions from and communicate directly with the person/assignee/attomey/firm/ organization 
who/which first sends/sent this case to them and by whom/which I hereby declare that I have consented after full disclosure to be 
represented unless/until I instruct Merchant & Gould P.C. to the contrary. 

Please direct all correspondence in this case to Merchant & Gould P.C. at the address indicated below: 
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Homer L. Knearl 
Merchant & Gould P.C. 
P.O. Box 2903 
Minneapolis, MN 55402-0903 
303.357.1633 

I hereby declare that all statements made herein of my own knowledge are true and that all statements made on information and belief are 
believed to be true; and further that these statements were made with the knowledge that willful false statements and the like so made are 
punishable by fme or imprisonment, or both, under Section 1001 of Title 18 of the United States Code and that such willful false 
statements may jeopardize the validity of the application or any patent issued thereon. 
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Full Name 
Of Inventor 


Family Name 

RODRIGUES 


First Given Name 

James 


Second Given Name 
P. 


0 


Residence 
& Citizenstiip 


City 

Redmond 


State or Foreign Country 

Washington 


Country of Citizenship 

USA 


1 


Post Office 
Address 


Post Office Address 

21858 NE 104th Place 


City 

Redmond 


State & Zip Code/Country 

Washington 98053/USA 


Signature of Inventor 2( 


)1: 


Date: 
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Full Name 
Of Inventor 


Family Name 

ANNANGI 


First Given Name 

Suneetha 




Second Given Name 




Residence 
& Citizenship 


City 

Issaquah 


State or Foreign Country 

Washington 


Country of Citizenship 

India 


;^ 


Post Office 
Address 


Post Office Address 

25447 SE 42nd Street 


City 

Issaquah 


State & Zip Code/Country 

Washington 98029/USA 


'^Signature of Inventor 202: 


Date: 



| L56 Duty to disclose information material to patentability. 



%J (a) A patent by its very nature is affected with a public interest. The pubhc mterest is best served, and the most effective 
ptent examination occurs when, at the time an application is being examined, the Office is aware of and evaluates the teachings of all 
lUformation material to patentability. Each individual associated with the filing and prosecution of a patent apphcation has a duty of 
^ndor and good faith in dealing with the Office, which includes a duty to disclose to the Office all information known to that individual to 
M material to patentability as defined in this section. The duty to disclose information exists with respect to each pending claim until the 
0im is canceled or withdrawn from consideration, or the application becomes abandoned. Information material to the patentability of a 
claim that is canceled or withdrawn from consideration need not be submitted if the information is not material to the patentability of any 
claim remaining under consideration in the application. There is no duty to submit mformation which is not material to the patentability of 
any existing claim. The duty to disclose all information known to be material to patentability is deemed to be satisfied if all information 
known to be material to patentability of any clahn issued m a patent was cited by the Office or submitted to the Office m the manner 
prescribed by §§ 1.97(b)-(d) and 1.98. However, no patent will be granted on an application in connection with which fraud on the Office 
was practiced or attempted or the duty of disclosure was violated through bad faith or intentional misconduct. The Office encourages 
applicants to carefully examine: 

(1) prior art cited in search reports of a foreign patent office in a counterpart application, and 

(2) the closest information over which individuals associated with the filing or prosecution of a patent application 
believe any pending claim patentably defines, to make sure that any material information contained therein is disclosed to the Office. 

(b) Under this section, information is material to patentability when it is not cumulative to information already of record or 
being made of record in the application, and 

(1) It establishes, by itself or in combination with other information, a prima facie case of unpatentability of a claim; 

or 

(2) It refiites, or is inconsistent with, a position the applicant takes in: 
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(i) Opposing an argument of unpatentability relied on by the Office, or 

(ii) Asserting an argument of patentability. 

A prima facie case of unpatentability is established when the information compels a conclusion that a claim is unpatentable under the 
preponderance of evidence, burden-of-proof standard, giving each term in the claim its broadest reasonable construction consistent with the 
specification, and before any consideration is given to evidence which may be submitted in an attempt to establish a contrary conclusion of 
patentabihty, 

(c) Individuals associated with the filing or prosecution of a patent application within the meaning of this section are: 

( 1 ) Each inventor named in the apphcation: 

(2) Each attorney or agent who prepares or prosecutes the application; and 

(3) Every other person who is substantively involved in the preparation or prosecution of the application and who is 
associated with the inventor, with the assignee or with anyone to whom there is an obligation to assign the application. 

(d) Individuals other than the attomey, agent or inventor may comply with this section by disclosing information to the 
attorney, agent, or inventor. 
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